前一篇提到，Review 與 Verify 都要跑時，後面的修正可能讓前面的檢查結果過期。我實際使用 Speclink 時，就遇過這個情況：Verify 通過了，原本完成的 Review 卻顯示「其後有變動」。
當時一份 change 已經完成 Review 並蓋章，後來 Verify 又從 specs 找到尚未實作的行為。等我把缺少的功能和測試補上，Verify 通過了，Speclink Desktop 右上角卻同時出現「已審查・其後有變動」與「已驗證」：
Review 當時看的是修改以前的 code。依照 Verify 的結果補完功能後，內容已經不同，前一次 Review 自然不能直接代表這份新的修改。
那麼，改成 Verify 先跑呢？假設 Review 後來又找到 Bug，修正後也可能換成 Verify 的章過期。光是交換順序，還是解決不了這個問題。
要知道怎麼讓兩邊一起收尾，我們先來看 Speclink 怎麼保存檢查途中找到的問題，以及完成後留下哪些紀錄。
【Day - 22】提過，Review 與 Verify 找到的問題與建議，也就是 findings，會分別保存在 change 資料夾的 review.md 與 verify.md。這兩份文件是檢查過程的工單，記住目前還有哪些事情要處理。
每次檢查與複驗，都會在對應文件新增一個 Round，留下當時檢查的內容與範圍。已經修好的問題不會再列在新一輪，還沒解決的則保留原文。所以換個 session 後，AI 可以從最後一輪繼續，不必重新猜前面處理到哪裡。
不過，找到問題不表示每一項都要立刻修改。Review 與 Verify 會用相同的三種嚴重度，幫我們區分哪些需要先處理、哪些可以自行取捨：
CRITICAL 是已有明確證據的錯誤，例如可能造成資料損失，或重要需求根本沒有完成；WARNING 則是很可能出現 Bug 的寫法，或實作與規格有明顯落差。這兩種歸在 must-fix，收尾以前要先決定怎麼處理。SUGGESTION 是讓 code 更好維護或更符合專案慣例的改善建議，可以留到之後再做。
單獨執行 Review 或 Verify 時，遇到 must-fix 就會停下來，讓我們選擇修正後複驗、確認接受風險並留下原因，或暫時不收尾。如果沒有 findings，或只剩 SUGGESTION，就可以完成這次檢查。完成時，Speclink 會移除對應工單，再把 stamp 寫進保存 change 基本資料的 .openspec.yaml。
工單記的是還沒處理完的問題，stamp 則記錄已經完成的檢查。那它怎麼知道，後來的 code 還是不是當時看過的那一份？
Review 與 Verify 會在 .openspec.yaml 留下各自的 stamp，記住當下的 task 總數，以及檢查範圍內每個檔案的路徑與內容指紋。內容指紋可以用來比對檔案有沒有改變；兩邊檢查的目的不同，記住的檔案範圍也不一定相同。
之後查看狀態時，工具就能比對目前的資料。如果相關內容有變動，原本的章會顯示「其後有變動」，提醒我們重新確認。這就是開頭那個畫面的原因：章記住的是當時的檢查結果，並不是對之後所有修改的保證。
既然後面的修正可能讓前面的章過期，我希望先把兩邊的問題都看過、該改的地方一起處理，再完成檢查。因此，我在 Speclink 加入了 Quality，安排 Review 與 Verify 一起收尾。
Quality 會先跑 Review，再跑 Verify，讓兩邊先留下結果，暫時不要蓋章。它沒有增加第三種檢查，而是安排這兩個流程接下來怎麼處理。
等兩份結果都回來後，Quality 會把 findings 放在一起，分開列出 must-fix 與其他建議，再停下來讓我們決定。需要修改，就由主要 session 處理 code 與測試；如果不需要修改，也會先詢問是否準備收尾，不會直接替我們蓋章。
修正並通過測試後，再依序讓 Review 與 Verify 複驗原本的問題，以及修正直接帶來的新問題。仍有需要處理的項目，就再次整理結果，停下來等我們決定。符合收尾條件，而且我們也同意後，才會連續蓋下兩個章。
這裡還有一種情況要分開處理：如果 Verify 發現需要調整的可能是規格本身，就要先回到 discussion 或 ingest 確認。不能只為了讓檢查通過，就把規格改成現在 code 的樣子。
把取得結果、決定是否修正，到最後確認收尾放在一起，流程就會像這樣：
這裡容易搞混： Quality 裡的 Review 與 Verify 是依序執行。【Day - 22】提到的平行 sub-agents 發生在 Review 內部，並不是兩種檢查同時進行。
透過 Quality 完成收尾後，兩份檢查結果就會對應到最後確認的內容。這時回到 Speclink Desktop，右上角就能同時看到「已審查」與「已驗證」：
看到兩個章都完成後，還要回頭確認 tasks 裡有沒有尚未完成的 [M] 人工驗收。這些需要使用者確認的工作，仍然要另外完成；如果是在 Worktree 裡實作，也要依照前面介紹的方式，先把修改合回主要 branch。
等這份 change 的工作都處理好，就可以在主要工作目錄執行 archive 了。前面我們已經留下規劃文件、實作紀錄與檢查結果，歸檔時，哪些會繼續保存，又會怎麼和正式 specs 接起來呢？
接下來，就來看看 Speclink 怎麼整理這份 change 最後留下的規格與紀錄吧！
iThome鐵人賽
看影片追技術